[762] Upgrade hudi version in xtable by vinishjail97 · Pull Request #772 · apache/incubator-xtable

vinishjail97 · 2025-12-17T02:05:25Z

Important Read

Please ensure the GitHub issue is mentioned at the beginning of the PR

What is the purpose of the pull request

Upgrades the hudi version to 1.1 which introduces many new exciting features for the lakehouse - Record Level Index, Secondary Index which can be leveraged by other table formats as well.
https://hudi.apache.org/blog/2025/11/25/apache-hudi-release-1-1-announcement/

Closes #833

Brief change log

(for example:)

Upgrade hudi version in xtable
Fix compile errors because of breaking changes
Derive the Hudi target database name from the target namespace (falls back to default_hudi)

Verify this pull request

This pull request is already covered by existing tests.

vinishjail97 · 2025-12-19T00:08:53Z

Error: ITConversionController.testVariousOperations:266->checkDatasetEquivalence:955->checkDatasetEquivalence:1029->lambda$checkDatasetEquivalence$10:1036 Datasets have different row counts when reading from Spark. Source: PAIMON, Target: HUDI ==> expected: <100> but was: <0>

The last test failure remaining to debug.

vinishjail97 · 2025-12-19T00:36:49Z

In Hudi 1.x, all the partition paths from MDT are coming in as empty causing the failures as compared to 0.x.

  protected List<PartitionPath> listPartitionPaths(List<String> relativePartitionPaths) {
    List<String> matchedPartitionPaths;
    try {
      if (isPartitionedTable()) {
        if (queryType == HoodieTableQueryType.INCREMENTAL && incrementalQueryStartTime.isPresent() && !isBeforeTimelineStarts()) {
          HoodieTimeline timelineToQuery = findInstantsInRange();
          matchedPartitionPaths = TimelineUtils.getWrittenPartitions(timelineToQuery);
        } else {
          matchedPartitionPaths = tableMetadata.getPartitionPathWithPathPrefixes(relativePartitionPaths);
        }
      } else {
        matchedPartitionPaths = Collections.singletonList(StringUtils.EMPTY_STRING);
      }
    } catch (IOException e) {
      throw new HoodieIOException("Error fetching partition paths", e);
    }

https://github.com/apache/hudi/blob/master/hudi-common/src/main/java/org/apache/hudi/BaseHoodieTableFileIndex.java#L346

vinishjail97 · 2025-12-20T01:53:16Z

CI is green, still looking into the following issues. PR can be reviewed for other aspects.

Paimon Source + Hudi Target + Unpartitioned test case fails because of MDT behavior change in 1.x. [Ref]
MDT col-stats are disabled.
Feature flags for table version 6 vs 9 in 1.x and let the user decide as part of target configuration.

vinishjail97

Performed a self review on the PR as the changes were large and few tests had to be disabled for CI to be green. Looking into the disabled tests and addressing self review comments.

vinishjail97 · 2025-12-22T19:56:19Z

   * @param commit The current commit started by the Hudi client
   * @return The information needed to create a "replace" commit for the Hudi table
   */
+  @SneakyThrows


Can we catch/throw actual exceptions and avoid @SneakyThrows in main repo?

Should we do this? catch and rethrow with some proper context for the user?

Done — there's no @SneakyThrows left in BaseFileUpdatesExtractor. Extraction/IO failures are caught and rethrown with context as ReadException, e.g. throw new ReadException("Failed to extract snapshot changes for Hudi table at " + tableBasePath, ex).

vinishjail97 · 2025-12-22T20:14:48Z

-                "nested_record.level:SIMPLE",
-                "nested_record.level:VALUE",
-                nestedLevelFilter)),
+        // Different issue, didn't investigate this much at all


What's the issue?

#775
Hudi 1.1 and ICEBERG partitioned filter data validation fails

vinishjail97 · 2025-12-22T20:15:01Z

-                "timestamp_micros_nullable_field:DAY:yyyy/MM/dd,level:VALUE",
-                timestampAndLevelFilter)));
+                severityFilter)));
+    // [ENG-6555] addresses this


What's the issue and why is the test disabled?

#775
Hudi 1.1 and ICEBERG partitioned filter data validation fails

SakthiKumaran-SP · 2026-05-15T07:30:50Z

any plan to merge this PR and support hudi 1.x ?

Reconcile the hudi 1.x upgrade with recent main changes. Take main's dependency versions wholesale (spark 3.4.2, delta 2.4.0, iceberg 1.9.2, paimon 1.3.1) since hudi 1.x publishes a spark3.4 bundle; only hudi.version differs from main. - HudiDataFileExtractor: adopt main's #816 fix (getAllReplacedFileGroups). - HudiFileStatsExtractor: merge main's #818 parquet-footer fallback with the PR's ValueMetadata/isV1 stats handling; getBasePathV2() -> getBasePath(). - TestHudiFileStatsExtractor: adapt #818 fallback tests to hudi 1.x APIs (getStorageConf/getStorage/getBasePath instead of getHadoopConf/getBasePathV2). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Bump hudi.version 1.1.0 -> 1.2.0 and migrate the 1.1 -> 1.2 breaking API changes: - Schema handling moved to HoodieSchema: HoodieAvroUtils.addMetadataFields -> HoodieSchemaUtils.addMetadataFields(HoodieSchema...); TableSchemaResolver .getTableAvroSchema[FromLatestCommit]() -> getTableSchema().toAvroSchema(); HoodieTableMetadataUtil.isColumnTypeSupported and HoodieAvroWriteSupport now take HoodieSchema. - Timeline: HoodieTimeline.compareTimestamps/GREATER_THAN -> InstantComparison; HoodieInstant.getTimestamp() -> requestedTime(). - TimelineMetadataUtils.serializeCleanMetadata -> serializeAvroMetadata. Drop the PR's incidental spark 3.4 -> 3.5 and delta 2.4 -> 3.0 bumps and keep main's versions; hudi 1.2.0 publishes a spark3.4 bundle so the upgrade does not require spark 3.5. Reverts delta-spark -> delta-core and the Delta 3.0 AddFile constructor (extra Option args) back to the 2.4 signature. Verified: full mvn install builds all modules; ITConversionController passes (43 tests, 0 failures). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

vinishjail97 · 2026-06-01T04:53:04Z

any plan to merge this PR and support hudi 1.x ?

@SakthiKumaran-SP The PR will be merged this week.

- TestHudiConversionSource: stub the 1.x metaclient APIs the HudiConversionSource ctor/cleanup path now uses (getStorageConf/getBasePath via doReturn for the StorageConfiguration<?> wildcard) and stub getActiveTimeline().readCleanMetadata (1.x) instead of getInstantDetails + serialized bytes. - HudiFileStatsExtractor: hudi 1.2.0's column-stats reader reports array elements with the parquet 3-level "list.element" path for both parquet footers and the metadata table, so always normalize array naming (drop the obsolete isReadFromMetadataTable branch) and collapse the now-identical name->field maps. - TestBaseFileUpdatesExtractor: temporarily disable the toString-based assertWriteStatusesEquivalent (see BLOCKER comment) — Hudi 1.2.0's WriteStatus toString embeds identity hashes and now serializes numInserts/recordsStats, which both breaks string equality and exposes stale hand-rolled expectations. To be replaced with a semantic comparison before merge. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Hudi 1.2.0 reflectively instantiates the parquet write support with the schema as a HoodieSchema (HoodieAvroWriteSupport's ctor changed), so the field-id subclass must mirror that signature. Take HoodieSchema directly and convert to Avro only where addFieldIdsToParquetSchema needs it. Fixes a NoSuchMethodException during writes (surfaced by ITRunSync.testContinuousSyncMode). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

the-other-tim-brown · 2026-06-05T18:29:17Z

-                    .setConf(hadoopConfiguration)
-                    .setBasePath(tableBasePath)
-                    .build();
+          HoodieTableMetaClient metaClient =


Previously this meta client was only build if the table existed. Does this handle the missing table gracefully now?

Yes, the missing-table case is handled gracefully. The HoodieTableMetaClient.builder()...build() plus schema resolution are wrapped in a try/catch, so for a not-yet-created table the TableNotFoundException thrown by build() is caught, logged at WARN, and currentSchema stays Option.empty(). The callback then proceeds with no field-id schema — same effective outcome as the old FSUtils.isTableExists(...) guard. The only behavioral difference is a benign WARN log on the very first sync of a brand-new table.

the-other-tim-brown · 2026-06-05T18:32:06Z

-            // https://issues.apache.org/jira/browse/HUDI-6954
-            .withMetadataIndexColumnStats(
-                !keyGenProperties.getString(PARTITIONPATH_FIELD_NAME.key(), "").isEmpty())
+            // TODO: Hudi 1.1 MDT col-stats generation fails for array and map types.


can we enable the stats when the array/maps are not present?

MDT col-stats can't be enabled in Hudi 1.2.0 even when arrays/maps are absent, because it couples the partition-stats index to the column-stats index. For partitioned tables the partition-stats generation path rebuilds a file-system view over the committed external parquet files and groups them by fileId; XTable's externally-registered files have non-Hudi names whose fileId cannot be parsed once the _hudiext marker is stripped, which leads to failures. So enabling col-stats here isn't viable yet — tracked in #773. (The commented-out schemaContainsArrayOrMap / TODO line is stale and will be cleaned up.)

the-other-tim-brown · 2026-06-05T18:36:09Z

   * @param commit The current commit started by the Hudi client
   * @return The information needed to create a "replace" commit for the Hudi table
   */
+  @SneakyThrows


Should we do this? catch and rethrow with some proper context for the user?

the-other-tim-brown · 2026-06-05T18:39:43Z

-                                23,
-                                Collections.singletonList(new IdMapping("double_nested_int", 25))),
-                            new IdMapping("level", 24))))),
+                                22,


why are the values updating?

The expected ids shift because the evolved-schema path now goes through the new updateIdMappings(...): existing top-level columns keep their original ids, while newly-added top-level columns (e.g. array_field, primitive_array_field) get the next sequential id, and nested ids are (re)generated per-column subtree rather than in one global pre-order pass over the whole schema. That changes the spacing/order of the nested ids (e.g. array_field 17→19, its element 21→20) while keeping ids stable within each column's subtree.

but why is the code path changing as part of the upgrade? will this break integrations for users?

You were right to flag this. I confirmed empirically that the updateIdMappings change was not required by the upgrade: with main's single-path generateIdMappings and only the forced API swap (HoodieAvroUtils.addMetadataFields was removed in 1.2.0, replaced by HoodieSchemaUtils.addMetadataFields), the original TestIdTracker passes unchanged (7/7 on hudi 1.2.0). The updateIdMappings branch was an independent behavior change that shifted field ids on schema evolution — which is exactly the integration-break risk you were pointing at for existing tables.

I've reverted it in b426c1f: getIdTracking is back to the single generateIdMappings path and the TestIdTracker expectations are restored to main's, so field ids stay identical to the pre-upgrade behavior. This keeps #772 a clean binary upgrade. If we want the evolution-time id handling changed later, it can land as its own PR with a test that fails without it.

Thanks for catching this, @the-other-tim-brown — really appreciate it. The updateIdMappings change wasn't meant for this PR; it slipped in through an accidental rebase and got picked up here. Reverted in b426c1f so #772 stays a clean binary upgrade.

I will create another PR behind a feature flag to update the mappings it's not required for the version upgrade.

the-other-tim-brown · 2026-06-06T19:43:39Z

+            ? HoodieSchemaUtils.addMetadataFields(HoodieSchema.fromAvroSchema(schema))
+                .toAvroSchema()
+            : schema;
+    if (currentId.intValue() != 0) {


I'm curious if this is an existing bug or something that happens due to changes in Hudi.

Not a pre-existing bug — it's an adaptation for the Hudi 1.2 schema path. getIdTracking now branches: when there's prior id-tracking state (currentId != 0, i.e. schema evolution) it calls updateIdMappings to preserve existing top-level ids and only assign ids to newly-added columns; the fresh-schema case (currentId == 0) still calls generateIdMappings. The old single-path generateIdMappings over HoodieAvroUtils.addMetadataFields regenerated everything, which didn't preserve ids across evolution.

the-other-tim-brown · 2026-06-06T19:49:36Z

+   * by column for new id assignment.
+   *
+   * <p>Different from generateIdMappings which traverse the entire schema tree, this method
+   * traverse individual columns and update the id mappings.


This method will call generateIdMappings which will traverse so I am not sure this comment is accurate

The javadoc now reflects this accurately — it states that updateIdMappings preserves the existing top-level mappings and delegates to generateIdMappings per column to (re)generate the nested mappings within each column's subtree. So the per-column traversal is called out explicitly rather than implying the method never traverses.

the-other-tim-brown · 2026-06-06T19:51:27Z

+        return ValueType.FLOAT;
+      case DOUBLE:
+        return ValueType.DOUBLE;
+      case STRING:


Should we add ENUM here?

Added — ENUM is handled in fromInternalSchema (it falls through with STRING, since enum values are stored as their string symbols in column stats), and there's a unit test for it (testFromInternalSchemaEnumMapsToString in TestXTableValueMetadata).

the-other-tim-brown · 2026-06-06T19:57:19Z

+            .filter(
+                hoodieInstant ->
+                    !hoodieInstant.isCompleted()
+                        || InstantComparison.compareTimestamps(


Lets make sure the tests are updated so we can properly test this switch to completion time

We've pulled the completion-time switch out of this PR. To keep backwards compatibility, this PR pins the write table version to 6 (old timeline view) and selects/orders instants by requested (instant) time. The completion-time handling and its parameterized v6/v9 tests will land with table-version-9 support in the follow-up PR, per the plan discussed above.

the-other-tim-brown

Let's make sure there is proper testing on completion time related changes before this is merged.

the-other-tim-brown · 2026-06-06T20:21:12Z

+    // We compare requestedTime of pending instants against completionTime of the last completed
+    // instant because pending instants don't have a completionTime yet. This captures pending
+    // commits that were initiated before or during the last completed commit's execution.
+    HoodieInstant lastCompletedInstant = completedInstants.get(completedInstants.size() - 1);


is completedInstants ordered by completion time? lets make sure there is a test to cover that.

For table version 6 the active timeline (and findInstantsAfter) is ordered by requested (instant) time, and that's the ordering completedInstants inherits here — so completedInstants.get(size-1) is the last by requested time, which is correct for the v6 semantics. Completion-time ordering and a test covering out-of-order completion come with the table-version-9 work in the follow-up PR; this PR deliberately stays on the v6 requested-time path.

vinishjail97 · 2026-06-22T22:55:33Z

Let's make sure there is proper testing on completion time related changes before this is merged.

@the-other-tim-brown Path for hudi 1.x upgrade in XTable, let me know if any changes are required.

Upgrade hudi binary to 1.x and keep the table format version pinned to 6 (the old timeline view), this ensures backwards compatibility with the previous version.
In HudiConversionTarget, enable a feature flag for using v9 and add changes required for completion time and parameterized tests for both v6/v9 handling, this will be in separate PR.
Iceberg Pluggable Table Format PR needs to be merged after above two are landed.

the-other-tim-brown · 2026-06-23T00:56:05Z

Let's make sure there is proper testing on completion time related changes before this is merged.

@the-other-tim-brown Path for hudi 1.x upgrade in XTable, let me know if any changes are required.

Upgrade hudi binary to 1.x and keep the table format version pinned to 6 (the old timeline view), this ensures backwards compatibility with the previous version.

In HudiConversionTarget, enable a feature flag for using v9 and add changes required for completion time and parameterized tests for both v6/v9 handling, this will be in separate PR.

Iceberg Pluggable Table Format PR needs to be merged after above two are landed.

@vinishjail97 sounds good to me. Once CI is passing on this PR, I can take another pass and approve.

… ITs - HudiConversionTarget/HudiTestUtil: enable MDT col-stats only for un-partitioned tables (avoids the partition-stats failure on externally registered files) and keep the test write config in sync. - ITHudiConversionTarget: parameterize tests for partitioned and un-partitioned tables; assert column stats only for the un-partitioned case. - ITConversionController: force eager file-index listing for the timestamp-partitioned case (lazy listing fails to parse partition values in 1.2.0); comment out the nested partition-column case (nested_record.level), which hits a Hudi 1.2 file-group-reader Avro schema limitation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TLw5GgCgbeubWrULQJc28r

Hive's hive-service (via xtable-hive-metastore) pulls in jetty-runner:9.3.20, an executable uber-jar that bundles stale Jetty 9.3.20 classes. Its ScheduledExecutorScheduler lacks the (String, boolean, int) constructor, so it shadowed jetty-util:9.4.54 on the test classpath and broke Hudi 1.2's embedded TimelineService (NoSuchMethodError) in the xtable-utilities ITs (ITRunSync, ITRunCatalogSync). jetty-runner is unused here, so exclude it and let the 9.4.x jetty-util with the required constructor be used. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TLw5GgCgbeubWrULQJc28r

vinishjail97 · 2026-06-25T22:35:30Z

@the-other-tim-brown Addressed all comments for v6 + getting a green CI, please review when you get a chance.

the-other-tim-brown · 2026-06-29T14:27:39Z

+                  // Hudi 1.2.0 couples the partition-stats index to the column-stats index. For
+                  // partitioned tables the
+                  // partition-stats generation path rebuilds a file-system view over the committed
+                  // external
+                  // parquet files and groups them by fileId; XTable's externally-registered files
+                  // have non-Hudi names
+                  // whose fileId cannot be parsed once the "_hudiext" marker is stripped, leading
+                  // to failures.


nit: fix formatting of the comments here

Thank you — addressed in 42bba3a. I've reflowed the comment into clean lines and pointed it at a dedicated tracking issue (#832) that explains why the column-stats index is currently gated to un-partitioned tables.

the-other-tim-brown · 2026-06-29T14:31:39Z

    </parent>

-    <artifactId>xtable-hudi-support-extensions_${scala.binary.version}</artifactId>
+    <artifactId>xtable-hudi-support-extensions_2.12</artifactId>


I think it makes sense to keep the extension dependent on the scala version

Agreed — reverted in 42bba3a. The module artifactId is back to xtable-hudi-support-extensions_${scala.binary.version} so it stays tied to the build-time Scala version.

the-other-tim-brown · 2026-06-29T14:31:44Z

        <dependency>
            <groupId>org.apache.xtable</groupId>
-            <artifactId>xtable-core_${scala.binary.version}</artifactId>
+            <artifactId>xtable-core_2.12</artifactId>


Done in 42bba3a — the xtable-core dependencies are back to xtable-core_${scala.binary.version} as well (both the compile dependency and the test-jar entry).

the-other-tim-brown · 2026-06-29T14:33:25Z

+    // run and reveal any other regressions. MUST be replaced, before this PR merges, with a
+    // semantic field-by-field comparison of fileId/partitionPath/path/numWrites/numInserts/
+    // totalWriteBytes/fileSizeInBytes plus recordsStats (columnName/min/max/null/value/totalSize).


Can you add this?

Done in ad48872. Replaced the disabled WriteStatus#toString comparison with a semantic field-by-field check: the WriteStat fields XTable populates (fileId/partitionPath/path/numWrites/numInserts/totalWriteBytes/fileSizeInBytes) plus the per-column record stats (min/max/nullCount/valueCount/totalSize), keyed by the column name embedded in each entry. The expected stats now match what convertColStats actually emits for the input (only leaf scalar columns survive, value counts are distinct per column, and the column-stats index is V1 for the pinned table version 6). The BLOCKER comment is gone.

the-other-tim-brown · 2026-06-29T14:34:06Z

          .setCommitTimezone(HoodieTimelineTimeZone.UTC)
          .setHiveStylePartitioningEnable(hiveStylePartitioningEnabled)
          .setTableType(HoodieTableType.COPY_ON_WRITE)
+          // Pin new tables to table version 6 for now. Table version 9 (Hudi 1.x) support will be


link issue here please

Added in 42bba3a — the v6-pin comment now links the umbrella issue #762 (Hudi version upgrade), under which the table-version-9 follow-up work is tracked.

…e default_hudi DB, link issues - HudiConversionTarget: rewrap col-stats comment cleanly, link #832 (new sub-issue of #762 for enabling col-stats on partitioned tables) - HudiTableManager: remove default_hudi DEFAULT_DATABASE_NAME workaround (reverts to default DB behavior), link #762 on the v6-pin comment - xtable-hudi-support-extensions pom: restore _${scala.binary.version}

Removing setDatabaseName(DEFAULT_DATABASE_NAME) regressed ITConversionController: under Hudi 1.x the target table lands in the "default" database and a Spark read resolves it as the colliding Delta table ("... is not a Hudi table"). Restore the dedicated database workaround; tracked in #774.

HudiTableManager hardcoded the database to default_hudi (a Hudi 1.x workaround for the default-database Delta collision). Allow callers to supply a database: HudiConversionTarget now uses the first level of the target namespace (targetTable.getNamespace()[0]) as the database name, mirroring how the Iceberg target consumes the namespace, and falls back to default_hudi when none is set.

… swap The updateIdMappings schema-evolution branch was not required by the Hudi 1.2.0 upgrade: with main's single-path generateIdMappings and only the forced HoodieAvroUtils -> HoodieSchemaUtils.addMetadataFields swap, the original TestIdTracker passes unchanged. updateIdMappings changed field-id assignment on schema evolution, which could shift ids for existing tables. Revert to main's behavior so field ids stay stable; restore main's TestIdTracker expectations.

Hudi 1.2.0's WriteStatus#toString embeds per-instance identity state, so the old toString-set comparison can no longer be used. Replace it with a field-by-field comparison of the WriteStat fields XTable populates (fileId/partitionPath/path/numWrites/numInserts/totalWriteBytes/fileSizeInBytes) and the per-column record stats (min/max/null/value/totalSize), keyed by the column name embedded in each entry. Rebuild the expected column stats to match production output for the input: only the leaf scalar columns survive convertColStats, value counts are distinct per column (so a stat mapped to the wrong column is caught), and the column-stats index is V1 for the pinned table version 6. Also set numInserts in the shared createWriteStatus helper and fix the partitioned test's file/stats assignment.

@disabled

The column-stats index is V1 at table version 6, where Hudi's isColumnTypeSupported excludes DECIMAL/FIXED columns (HUDI-8585), so a decimal column gets no col-stats. Align TestHudiFileStatsExtractor to table version 6 (mocks set HoodieTableVersion.SIX) and assert 8 of 9 columns (decimal dropped), replacing the stale @disabled. Parameterizing these tests over table version 6/9 is tracked in #834. Also link #834 from the v6-pin comments in HudiTableManager and HudiConversionTarget.

vinishjail97 · 2026-06-30T00:52:10Z

Thanks for the thorough review, @the-other-tim-brown! I've addressed all the comments:

IdTracker — reverted to single-path generateIdMappings, keeping only the API swap.
default_hudi — database is now derived from the target namespace, falling back to default_hudi.
WriteStatus — replaced the disabled toString() check with a full semantic comparison.
Decimal column stats — documented the table-version-6 (index V1) behavior (HUDI-8585) and aligned tests to v6.

Could we merge this binary-upgrade PR and handle the follow-ups incrementally? I've filed them as sub-issues under #762: #832 (col stats for partitioned tables) and #834 (table version 9 support). #833 is resolved by this PR.

…ble version 9 Re-enables the three conversion cases apache#772 disabled for the Hudi 1.x target: - Un-partitioned Paimon -> Hudi (ITConversionController and ITConversionService). BaseFileUpdatesExtractor now emits Hudi's external file-group-prefix format (Hudi PR #17788) for bucketed files instead of folding the "bucket-N" directory into the partition path: the file is registered under its true partition (empty for un-partitioned) with fileId "bucket-N/<file>" and the 3-arg marker "<file>_<commit>_fg%3Dbucket-N_hudiext". Applied consistently across the snapshot path, the diff path, and file-id derivation; non-bucketed sources are unaffected. - HUDI (partitioned on the nested column "nested_record.level") -> ICEBERG. This depends on the Hudi reader fix in apache/hudi#19123, so it will only pass once that fix is available in the Hudi snapshot the build resolves. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

vinishjail97 added 2 commits December 16, 2025 17:31

Upgrade hudi version in xtable

10ec210

Fix hudi source tests

bc6b611

vinishjail97 mentioned this pull request Dec 17, 2025

Hudi Version Upgrade #762

Open

2 tasks

vinishjail97 added 4 commits December 16, 2025 18:37

Fix few more tests

9246036

Fix more tests

f854079

Fix more tests-2

c8b23d5

Remove zero row group test

61e48de

vinishjail97 added 3 commits December 18, 2025 17:41

Disable test for Paimon source, Hudi target and un-parittioned

6eba339

Fix more tests-4

43ff8bb

Fix more tests-5

6923779

vinishjail97 changed the title ~~Upgrade hudi version in xtable~~ [762] Upgrade hudi version in xtable Dec 20, 2025

vinishjail97 marked this pull request as ready for review December 20, 2025 01:52

vinishjail97 commented Dec 22, 2025

View reviewed changes

Address self review comments and link GH issues for failing tests

8d3c7e0

vinishjail97 mentioned this pull request Apr 8, 2026

Upgrade to spark version 3.5 #671

Closed

vinishjail97 and others added 2 commits May 31, 2026 21:25

vinishjail97 and others added 2 commits June 1, 2026 00:00

the-other-tim-brown reviewed Jun 5, 2026

View reviewed changes

the-other-tim-brown reviewed Jun 6, 2026

View reviewed changes

the-other-tim-brown requested changes Jun 6, 2026

View reviewed changes

vinishjail97 and others added 2 commits June 24, 2026 11:44

the-other-tim-brown reviewed Jun 29, 2026

View reviewed changes

vinishjail97 added 4 commits June 29, 2026 13:24

vinishjail97 mentioned this pull request Jun 29, 2026

Add Hudi table version 9 (Hudi 1.x) support to the Hudi target #834

Open

2 tasks

vinishjail97 added 3 commits June 29, 2026 16:28

Tidy up comments in BaseFileUpdatesExtractor test

c7cd096

the-other-tim-brown approved these changes Jun 30, 2026

View reviewed changes

vinishjail97 merged commit 4280b60 into main Jun 30, 2026
2 checks passed

vinishjail97 deleted the hudi-upgrade-version branch June 30, 2026 02:04

Uh oh!

Conversation

vinishjail97 commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Important Read

What is the purpose of the pull request

Brief change log

Verify this pull request

Uh oh!

vinishjail97 commented Dec 19, 2025

Uh oh!

vinishjail97 commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vinishjail97 commented Dec 20, 2025

Uh oh!

vinishjail97 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

SakthiKumaran-SP commented May 15, 2026

Uh oh!

vinishjail97 commented Jun 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

vinishjail97 commented Dec 17, 2025 •

edited

Loading

vinishjail97 commented Dec 19, 2025 •

edited

Loading